1. Field of the Invention
The present invention relates to Binding Updates and Binding Acknowledgments in Mobile Internet Protocol version 6 (Mobile IPv6 or MIPv6).
2. Description of the Related Art
Internet and Internet Protocol (IP) were first built to ensure data transfer from one or more information servers to a fixed host. A lot of functionalities were then added in order to provide mobility to the still fixed host while accessing information stored in the servers. We are now faced with the challenges of having multiple ends of an IP communication all moving at the same time.
Mobile IP version 4 (Mobile IPv4, Mobile IP, MIPv4 or MIP) and the current version of MIPv6 are built to provide mobility to a host or Mobile Node (MN). The other nodes, usually referred to as Correspondent Nodes as (CN), are usually seen as fixed hosts. Reference is now made to the drawings where FIG. 1 shows a MIPv6 network architecture as suggested by the current MIPv6 specification found in an Internet Engineering Task Force (IETF)'s Internet draft named “draft-ietf-mobileip-ipv6-24”, herein included by reference. As can be seen in FIG. 1, an IP network 100 comprises a MN 110 in communication with a CN 120 on a link 122. The link 122 is unlikely to be composed of only one direct physical connection, but rather represents a series of links between routing equipments transparently enabling the communication therebetween. The way the series of links is used to transport traffic between the MN 110 and the CN 120 is irrelevant as long as IP communication therebetween can be established.
The MN 110 has a permanently assigned home address valid in its home network 127, which home address is allocated upon initialization of the MN 110 in the home network 127. The allocation mechanism falls outside the scope of the present invention. The MN 110 is further in communication with a Home Agent (HA) 130 located in its home network 127. Among other functionalities, the HA 130 keeps record of a foreign address of the MN 110 valid outside the home network 127. The foreign address is called Care-of-Address (CoA) in the context of MIPv6. The CoA assigned to the MN 110 changes in time as the MN 110 moves from one network to another. The record kept by the HA 130, referred to as binding in the context of MIPv6, ties the CoA to the home address. A binding between the home address and the CoA is also kept in the CN 120 for the purpose of reaching the MN 110. The HA 130 is also responsible for routing traffic received at the home address to the MN 110. The traffic received is forwarded by the HA 120 on a link 125 toward the MN 110. All traffic sent on the link 125, in accordance with MIPv6, is encrypted to ensure, among other things, confidentiality of credentials periodically exchanged between the MN 110 and the HA 130. It should be noted that the MN 110 may have multiple home addresses and multiple CoA addresses and that a binding should be kept at the HA 130 for each pair of home address-CoA.
The following lines is an example of how the MIPv6 concept applies in a typical situation. For the benefit of the example, the MN 110 is in bidirectional IP communication with the CN 120 on the link 122. When the MN 110 moves from a first network to another, as illustrated by an arrow 135 on FIG. 1, the MN 110 receives a new CoA. This modification in addressing state of the MN 110 must be advertised to the CN 120 and the HA 130. Prior to the advertisement, the MN 110 must first make sure that the home address, which did not change, is still valid and that the newly acquired CoA address is usable to communicate with the CN 120. This assessment is done via a return routability (RR) test or procedure. The RR procedure also allows the creation of an authentication key. For this purpose, a Care-of init cookie and a home init cookie are built by the MN 110, also protecting the RR procedure from being spoofed.
The RR procedure starts at the MN 110, which sends a Home Test Init (HoTI) message through the HA 130, on the link 125, using its home address as the source address. The HoTI message contains the home test init cookie and is addressed to the CN 120. Upon reception of the HoTI message, the HA 130 forwards it to the CN 120 on a link 140. The link 140 has the same characteristics as the link 122. Simultaneously to sending the HoTI message, the MN 110 sends a Care-of Test Init (CoTI) message containing the Care-of Init cookie toward the CN 120 on the link 122 with its new CoA as the source address.
Upon reception of the CoTI message, the CN 120 replies with a Care-of Test (CoT) message addressed to the source address of the CoTI message (i.e. the MN's 110 new CoA) on the link 122. The CoT message contains the Care-of Init Cookie and a care-of keygen token generated by the CN 120. Upon reception of the HoTI message, the CN 120 replies with a HoT message addressed to the source address of the HoTI message (i.e. the MN's 110 home address) on the link 140. The HoT message contains the home Init Cookie and a home keygen token generated by the CN 120. Reception of the CoT and HoT messages at the MN 110 successfully completes the RR procedure. The MN 110 keeps the content of both the HoT And CoT messages and then continues with the advertisement of the modification of its CoA toward the CN 120 and the HA 130.
In order to advertise modification to its CoA, the MN 110 sends a first Binding Update (BU) message to the HA 130 on the encrypted link 125 containing the newly acquired CoA and other information related to the HA 130 binding. The detailed content of the BU as such is not related to the present invention. The HA 130 then updates its corresponding binding and replies to the MN 110 with a first Binding Acknowledgment (BA) indicating the successful update of the binding. The MN 110, after sending the first BU, uses the care-of keygen token and the home keygen token received earlier from the CN 120 to generate an authentication key Kbm valid between the MN 110 and the CN 120. The authentication key Kbm is commonly referred to as binding management key in the context of MIPv6. The MN 110 then creates a second BU similar to the first BU, signs it with the key Kbm and sends it to the CN 120 on the link 122. The CN 120, upon reception of the second BU or before, generates the same key Kbm using the tokens it already generated and further verifies the received second BU before updating its own related bindings. The CN 120 then creates a second BA, signs it using the key Kbm and sends it, in accordance with the MIPv6 specification, on the link 125 toward the HA 130, but addresses the second BA to the MN 110. The HA 130 simply forwards the second BA to the MN 110. Reception of the second BA at the MN 110 indicates the successful completion of the advertisement of the modification.
In the example of FIG. 1, the MN 110 is in active information exchange with the CN 120 only. When multiple end points are present, advertisement of the modification involves the repetition of the previously described behavior. More precisely, the RR procedure must first be performed with each of the end points. Similarly, an authentication key and a BU must be generated for each supplementary end point. Generated keys are then used to sign each BU prior to respectively sending them toward each supplementary end point.
As one skilled the art shall know, handheld devices usually have strictly limited processing capabilities. Since we are constantly progressing toward mobility, such handheld devices need to be able to use MIPv6 without problems. A key to the success of MIPv6 on such devices is then to limit the amount of processing required therefrom and, at the same, to free the available processing capabilities for quality of speech, image and so on. For MIPv4, attempts have been made to refrain the MN 110 from sending multiple BU to multiple end points. However, those attempts did not take into account encryption and authentication of the BU as required by MIPv6. In other words, the attempts could not comply with security concepts prescribed by the MIPv6 specification. As it can be appreciated, a solution to reduce the processing load of handled devices in the context of MIPv6 is needed.
The present invention provides such a solution.